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(57) Abstract 

Computer network management for electronic commerce requires technical implementations of business processes. The process 
addressed here is a technical method for a communication in which two or more parties legitimately want to communicate anonymously, 
often before discussing a deal or closing a business, e.g. for anonymous bidding or auctioning in electronic commerce. Essentially, the 
invention is a method, described by a protocol, for safely exchanging data in a network that provides a public key infrastructure and an 
anonymous communication possibility between network users. It consists of a sequence of steps in which both parties, sender, e.g. customer, 
and addressee, e.g. merchant, compose data sets, i.e. requests and replies, that arc based on received data and/or prior knowledge. The 
data sets are enciphered, as far as necessary to provide anonymity, and digitally signed, as far as necessary to provide proof of the partner. 
The invention is also a system designed to implement the invented method. 
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1 DESCRIPTION 

Secure Anonymous Information Exchange in a Network 

5 



TECHNICAL FIELD 

10 

The present invention lies in the field of computer network management, it 
specifically concerns the technical implementation of a business process in 
a computer network environment. The processes addressed here are of the 
type where two or more parties legitimately want to communicate 
is anonymously, often before they discuss a deal or close a business. The 
invention does not concern a business process by itself, but underlying 
technical methods used to execute one or the other business process. In 
particular, the invented method may be used for anonymous bidding or 
auctioning in electronic commerce. 

20 

BACKGROUND OF THE INVENTION 

Obviously, both the importance and the proliferation of electronic commerce 
continue to grow; the Internet is a striking example. In such an environment 
25 - analogous to the traditional "non-electronic" commerce - consumer privacy 
is becoming a major concern. 

However, the mere fact that electronic commerce is conducted over an 
existing open network infrastructure such as the Internet runs counter to the 
30 privacy of the consumer. Often, there are legitimate reasons for a party to 
remain anonymous at least during an initial stage of a developing (business) 
relationship with another party. But it becomes very difficult or even 
impossible for a party to protect or hide his/her identity when he/she 
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i addresses another party over an open network. And, of course, this 
anonymity issue becomes even more complex when both communicating 
parlies want to stay anonymous. 

s This is essentially due to the end-to-end nature of application protocols that 
are mainly used as a vehicle for electronic commerce: World Wide Web 
(WWW), Electronic Mail, File Transfer (FTP), and others. 

Prior Art 

10 

The anonymity issue mentioned above was already addressed before: US 
Patent 5 375 055 to Dunne et al. is an example, though in a different 
environment as the present invention and thus only of limited relevance. 
The Dunne patent discloses an electronic brokerage system in a 

15 communication network connecting traders dealing in financial instruments. 
In this computerized system, anonymous price quotes are distributed 
selectively in accordance with previously established credit limits. This 
system includes a so-to-speak central instance that that has all the 
information available, but communicates only part of it to the connected 

20 parties. 

Already from the outset, this is quite different from the goal of the present 
system which is to provide a secure method that allows one parly, e.g. a 
user, a consumer, or a bidder, to obtain quotes/bids/offers from another 
25 party, e.g. a prospective merchant, over an open network without sacrificing 
his/her privacy, i.e. while remaining anonymous. 

Another specific approach is disclosed in US Patent 5 420 926 to Low et al. 
This patent describes techniques for performing credit-card transactions 
30 without disclosing the subject matter of the transaction to the institution 
providing the credit card. The techniques include the use of an 
intermediary, called communication exchange, for the exchange of 
information and funds without the destination for the transfer knowing the 
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source of the information or funds. Public key encryption is used so that 
each party to the transaction and the communications exchange can read 
only the information the party or the exchange needs for its role in the 
transaction. 

Though the Low patent describes a method for hiding transaction details 
from the parties concerned, it focuses on the goal to restrict each of the 
corresponding parties from getting more than the minimum amount of 
information required for executing the transaction. This is, in general, 
relevant to the present invention, however, the techniques proposed in the 
Low patent do not solve the anonymous bidding problem, which requires 
the exchange of sufficient detail information between two or more parlies 
with only a minimum of intermediary action to solve the anonymity issue. 

Another example for a technology that addresses the issue of privacy and 
anonymity of "electronic consumers" or subscribers, providing some degree 
of electronic privacy, is the so-called electronic/digital cash as described, 
e.g. by D. Chaum et al. in "Untraceable Electronic Cash" in Proceedings of 
CRYPTO'88, August 1988, Santa Barbara, CA, USA. 

Here, again, the situation differs from the present invention, since the 
information to be transmitted is restricted to financial transactions that have 
to be safely executed. This allows a closely formalized process with a 
minimum of "free text" to be considered or handled. The present invention, 
on the other hand, must allow practically free text communication, at least 
from the user side. This obviously poses additional problems not solved by 
digital cash implementations as the one cited above. 

Objects of the Invention 

From the outset, the nature of most current network protocols and 
applications is adverse to privacy. The vast majority of protocols used have 
one thing in common: they faithfully communicate end-point identification 
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information. "End-point" in this context is meant to denote a user (with an 
ID), a network address, or an organization name. For example, electronic 
mail (e-mail) routinely communicates a sender's address in its header(s). 
File transfer (e.g. FTP), remote login (e.g. TELNET), and hypertext browsers 
(e.g. WWW) expose addresses, host names and IDs of their users. This is 
not a problem for most applications. 

However, as said above, there are legitimate reasons why a user does not 
want to sacrifice his/her privacy, e.g. by performing an innocent activity 
o such as "browsing" a catalog via WWW or inquiring about some 
merchandise via e-mail. Particularly in the latter case, there are often sound 
economic reasons why a potential customer does not want to disclose 
his/her identity. 

5 Starting from this, the main object of this invention is to provide a method 
which enables such anonymous data exchange, e.g. a method how a 
prospective customer may obtain bids or offers from prospective merchants 
without disclosing his/her identity. Another example is a user's anonymous 
bidding in an auction conducted over a network. 

o 

Further in this direction is it another object of the invention to disclose a 
method by which the offering merchant may also, selectively upon his/her 
desire, protect his/her privacy up to a certain point of the usual sales 
process - or even through the whole process. 

5 

A particular object is to provide a system that is resistant to false 
representations from both sides, the sender's (bidder or customer) as well 
as the addressee's (auctioneer or merchant). 

0 A still further object is to employ and exploit known services, already 
available on many networks, for this purpose, and thus minimize the 
additional effort and expenditure for implementing the invention. 
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i SUMMARY OF THE INVENTION 

In a network thai provides a way for anonymous communication and a 
public key infrastructure, and perhaps even public key certification (PKC), 

5 the invention provides a method for the desired secure, but anonymous 
communication. In brief, a sender initially composes an encrypted request 
containing a "subject question" and his/her digital signature. This request is 
sent anonymously to one or more addressees. Each addressee then 
composes an encrypted reply, including a "subject answer" and his/her 

to digital signature. "Subject question" and "subject answer" are meant to 
denote corresponding pairs of information sets used in the particular 
business, e.g. a description of a particular merchandise and the 
corresponding offer from a merchant, or the request for a particular service 
and the corresponding offer of a service provider, or a bidder's bid at an 

is auction and the auctioneer's answer. 

The invention shall be explained in more detail by the example of 
anonymous bidding (which usually predates a purchase). 

20 Prerequisites, as mentioned above, are the possibility of anonymous 
communication and a public key infrastructure. The process is started by a 
sender, usually a prospective customer or consumer, who composes an 
offer request with a plain, i.e. not encrypted, description of the desired 
product or service and his/her digital signature. One must be aware that 

25 such a digital signature does not by itself reveal the sender's identify. This 
offer request is sent anonymously to one or more selected addressee(s), or 
even broadcasted, via the network. Addressees are merchants, service 
providers, or the like. Since the offer request itself is in plain language, 
every addressee may read it and decide whether to make a bid. If an 

30 addressee decides to do so, he/she composes a reply with an offer 
description and his/her digital signature, which "includes" the sender's 
digital signature, and mails it to the sender. The addressee's public key may 
also have to be transmitted if it must be assumed that the sender does not 
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t have access to it. From the received message and the addressee's public 
key, the sender can now compute two values (a first and a second) whose 
matching indicates the genuineness of the offer. So much for the bidding 
process. 

5 

It should be clear to someone skilled in the art that the invention can be 
even more advantageously implemented in a network providing public key 
certification (PKC). 

10 Further, an actual sale, following the bidding process above, may be 
organized along the same line. In this case, the sender also uses the 
existing public key infrastructure. The sender, i.e. the prospective customer, 
transmits a proof to the merchant, who, in turn, uses sender's public key to 
calculate a third value and determines a fourth value by applying a hash 

is function to certain parts of the received message, and, by comparing these 
two latter values, determines genuineness of said offer. This makes the 
invented method resistant to cheating by both sender and addressee. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

In the accompanying drawings show 

Fig. 1 the general layout of a network in which the invention can be 
25 used; 

Fig, 2A the data exchange according to a first part of the invention; 



Fig. 2B 

30 

Fig. 3 



the data exchange according to a second part of the invention; 
the data exchange according to a modification of the invention. 
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i Preferred Embodiments 

The method described in the following is a generic approach for obtaining 
bids or offers from "electronic merchants'' without any sacrifice in consumer 
5 privacy. As an extension, it offers protection to the merchants by allowing 
them to accept only genuine bids from consumers and, if need be, reliably 
associate a consumer with a previously issued blind bid. Moreover, 
merchants can detect replays or duplicates of bids that had already been 
acted upon. 

10 

The anonymous bidding method according to this implementation of the 
invention requires certain basic security services for its proper operation: 1. 
a provision for anonymous message-based communication, and, 2. a 
public-key certification (PKC) infrastructure. Both are briefly addressed 
15 below. 

First, an anonymous communication channel is required. At the start, 
anonymous communication is necessary to preserve anonymity of the 
sender, i.e. the prospective consumer in this context. It is also used to hide 
20 the location of the sender, since the sender's identity and his/her location 
are often tightly coupled. 

There is a simple way of achieving some kind of anonymity, no matter 
whether synchronous or asynchronous communication is used. If the 
25 sender, i.e. the consumer, customer or bidder, works from a public terminal, 
the address of the latter usually does not allow identification of the party 
using it and thus provides anonymity. 

More complex, but more secure, are networks that provide a special tool for 
30 such anonymous, message-based communication. For both synchronous 
(e.g. WWW) or asynchronous (e.g. usual e-mail) networks, appropriate tools 
are available and known. In the case of synchronous communication, a 
protocol specific anonymizer may be used, being essentially a program that 
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functions as a conduit between the real sender and the addressee, hiding 
the identity of the sender, e.g. by using a random alias. 

An example of synchronous anonymizer can be easily built on top of a 
network gateway/firewall such as the IBM "NetSP Secured Network Gateway 
for AIX", short "SNG" in the following IBM Publications: 

- SC31-8113 - NetSP SNG Installation, Configuration and Administration 
Guide, and 

- GG24-2577 - Implementing an Internet Firewall with NetSP SNG. 

A typical firewall already anonymizes outgoing traffic by rewriting source 
addresses with its own. It is only necessary to allow the same for incoming 
traffic, i.e. to overwrite the source addresses with the firewall's network 
address, in order to make it an anonymizer. 

In the case of asynchronous communication, an anonymous relay service 
may be used. One example is the anonymous remailer, an anonymous relay 
for e-mail. While anonymizers for synchronous communication are not yet 
widely used, anonymous remailers are widely known on the global Internet; 
there are many available, offering different degrees of anonymity and 
interoperability. 

One example of a working anonymous remailer is the PENET service 
operated in Finland by J. Helsingius. Another is the MIXMASTER remailer 
distributed by L. Cottrell and operated by several sites in the US. 

The PENET remailer is available from the World Wide Web, WWW, at 
"http://www.penet.fi". The information under this address includes a paper 
by J. Helsingius on remailers, entitled Tenet Anonymous Remailer 
Service", and addresses of remailers. The MIXMASTER remailer is available 
via the WWW at "http://obscura.eom/#loki/remailer-essay.html". A paper by 
L. Cottrell on remailers, entitled "Mixmaster and Remailer Attacks", and 
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more information on anonymous remailers can be found under this WWW 
address. 



Generally, anonymous bidding places almost no restrictions on the type of 

5 the anonymizing tools. The only exception is the requirement for two-way 
communication; in other words, it should be possible for a prospective 
consumer, customer, or bidder (sender) to send an anonymous request to a 
prospective merchant or auctioneer and for the latter to reply to the sender. 
This can be done in a number of ways. One method used by simple existing 

io anonymous remailers is to set-up a table that maps real e-mail addresses 
into aliases; this way, an addressee (merchant) can reply to the alias that is 
subsequently translated into a real e-mail address by the anonymous 
remailer. There are also more secure and sophisticated methods such as 
having the sender precompute a secret return path thai is then "blindly" 

15 used by the addressee. Suffice it to say that, as long as it is available, the 
person skilled in the art can easily select an anonymity system that satisfies 
the requirements. Examples for solutions to the anonymity requirement can 
be found In D. Chaum, "Untraceable Electronic Mail, Return Addresses and 
Digital Pseudonyms" in Communications of the ACM, Vol.24, No.2, Feb. 

20 1981, and C. Gulcu and G. Tsudik, "Mixing Email with Babel" in Proceedings 
of ISOC Symposium on Network and Distributed Systems Security, Feb. 
1996, San Diego, CA, USA. 



The second requirement is a public key infrastructure. Most of them are 
25 designed as public key certification method (PKC). Such PKCs are available 
on networks today, serving a multitude of purposes. Currently, their most 
prominent use is in the area of secure electronic mail. Two widely used 
examples are Privacy-Enhanced Mail (PEM) and Pretty Good Privacy (PGP). 
PEM includes a PKC hierarchy and functions. PGP is somewhat "ad hoc", 
30 although it allows for informal certification hierarchies. It can be safely 
assumed that PKC will be a cornerstone of most future electronic commerce 
products. Such PKC methods are described in Bruce Schneier in "Applied 
Cryptography", New York 1995 by John Wiley and Sons, Inc. 
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In the detailed description below it is assumed that all relevant parties, 
senders/consumers and addressees/merchants, are equipped with 
individual public key certificates. At the very minimum, a certificate is 
assumed to contain the party's name, public key, validity time, and the 
name of the issuing authority, the latter being often referred to as 
"certification authority". 

Notation Used 

The table below gives the notation used throughout the following 
description, the drawings, and the claims. 



15 



20 



25 



30 



C,M 

MD 

OD 

REQ 

REP 

ACC 

TEMP-a 

ID-X 

PK-x 

SK-x 

R-x 

Cert-x . 

K(text) 

H(text) 



SIG-x 
{text} 



- Consumer and Merchant, the protocol participants; 
technically they are "sender" and "addressee"; 

- Merchandise description; 

- Offer description; 

- Offer request; 

- Offer reply; 

- Offer accept; 

- Temporary value a; 

- user ID of X; 

- Public key of X (X = C or X= M); 

- Secret/Private key of X; 

- Random number (nonce) generated by X; 

- Public Key Certificate of X, includes PK-x; 

- Encryption of "text" under key K; 

- Strong one-way Hash function upon "text", e.g. SHA 
(Secure Hash Function) or MD5, both described in 
Bruce Schneier: Cryptography, above; 

- Signature of X; 

- Optional text 
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Description of the Basic Process (Transferable Voucher) 

The following is a detailed description of the basic process according to the 
invention as claimed. 

1. Consumer Request 

A consumer C wishing to obtain a bid/offer from a merchant M for certain 
merchandise composes the following message; 

OFFER-REQUEST = MERCHANDISE-DESCRIPTION, SIG-c, 
wherein: 

- MERCHANDISE-DESCRIPTION, MD in the drawings, is the textual 
description of the desired merchandise including, e.g. quantity, 
color/size, delivery dates, etc.; 

- SIG-c = H(MERCHANDISE-DESCRIPTION, R-c) 

SIG-c is thus the hash function digest of MERCHANDISE-DESCRIPTION 
together with a randomly-generated, used-only-once quantity, a nonce R-c. 
The preferred minimum recommended length for R-c is 64 bits. 

A crucial detail is that, although R-c is used in computation of SIG-c, R-c is 
not included as part of the OFFER-REQUEST message. 

As shown in Fig.1, after composing OFFER-REQUEST, the prospective 
consumer (1) uses the anonymous communication service (3, 4), e.g. 
anonymous remailers, to send the message to the merchant (2) or a number 
of merchants. Any of them can read the description of the desired 
merchandise. 
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2. Merchant Reply 

As said above, upon receiving OFFER-REQUEST, merchant M is not 
required to perform any security-related activity. Instead, he/she examines 
5 MERCHANDISE-DESCRIPTION and determines whether or not he/she can 
make a corresponding offer/bid. This process depends both on merchant M 
and on the type of merchandise specified in the incoming request. It and 
when the merchant is ready to make an offer, he/she composes the 
following message: 

10 

OFFER-REPLY = OFFER-DESCRIPTION, SIG-m, 
{H(MERCHANDISE-DESCRIPTION, SIG-c)} ( {Cert-m}, 
wherein: 

15 

- OFFER-DESCRIPTION (OD in the drawings) is the plain text description 
of the offer including, e.g. current date/time, price, currency, accepted 
payment type, delivery schedule, etc. 

20 

» SIG-m = SK-m[H(SIG-c, MERCHANDISE-DESCRIPTION, 
OFFER-DESCRIPTION)]. 

- MERCHANDISE-DESCRIPTION and SIG-c are as in OFFER-REQUEST 
message, both are optional. 

25 

- CERT-m is the public key certificate of merchant M, if available: it is 
optional. It may be known to consumer C independently. 

Cert-m, the merchant's public key certificate, may not be available in a 

30 

network, e.g. one that does not provide PKC service. Then, only the bidding 
process according to the invention may be executable. Transmitting Cert-m 
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i is certainly optional; even when it is required for the subsequent sale 
process, it is quite possible that the customer already has it. 

The hash function digest of MERCHANDISE-DESCRIPTION and SIG-c is also 
5 optional since its only use is to help customer C to match the outstanding 
OFFER-REQUEST with the incoming OFFER-REPLY. This is only necessary, 
in principle, when an asynchronous communication channel is used. 

3. Subsequent Actions by Consumer 
io When the consumer receives OFFER-REPLY, he/she executes the following 
actions: 

a. If applicable, recomputes H(MERCHANDISE-DESCRIPTION, SIG-c) and 
identifies the matching OFFER-REQUEST. 

15 

b. If applicable, verifies the validity, authenticity and data integrity of the 
merchant's certificate Cert-m. (Techniques for doing this are known, cf. 
Bruce Schneier: Cryptography, cited above) 

20 c. Examines OFFER-DESCRIPTION for consistency with the corresponding 
MERCHANDISE-DESCRIPTION and determines whether to accept the 
offer. 

d. If the offer is not accepted, no further actions are taken. 

25 

e. If the offer is of interest, consumer C computes: 

- Temporary value TMP-1 

TMP-1 = PK-m(SIG-m), where PK-m is Ihe merchant's public key 
30 extracted from Cert-m. 

Temporary value TMP-2 

TMP-2 = H(SIG-c, MERCHANDISE-DESCRIPTION, 
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OFFER-DESCRIPTION) 

f. Finally, he/she compares TMP-1 and TMP-2 and, if they match, is 
assured that the offer is genuine. 

The above process is shown in Fig. 2A in an abbreviated fashion. 

Given that the offer is acceptable and genuine, the consumer - if he/she so 
wishes - can approach the merchant directly, i.e. without going through the 
o anonymizing process. This is usually the case when goods of a physical 
nature have to be delivered. Anyway, the consumer may decide to act upon 
the merchant's offer some time after the initial exchange, e.g. the next day. 

If the merchandise is of electronic nature and can be delivered on-line, e.g. 
5 some software or data, it may be possible and desirable for consumer C to 
remain anonymous. This can be done by going through the anonymizing 
process in the delivery stage again. However, in many cases consumer C 
will resort to conventional methods of payment (e.g. credit card) in which 
case his anonymity is likely to be sacrificed. 

4. Subsequent Actions 

The final step in the blind bidding method according to a further pari of the 
invention involves the merchant verifying the validity of the offer once the 
consumer decides to accept it. Regardless of how the consumer goes about 
it, the following five items of information must be communicated to the 
merchant: 

MERCHANDISE-DESCRIPTION 
SIG-c 

OFFER-DESCRIPTION 
SIG-m 
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1 The first four can be taken directly from the aforementioned 
OFFER-REQUEST and OFFER-REPLY messages. The missing R-c is the 
hereto secret quantity that was used to compute SIG-c as explained above. 

5 To show his acceptance of the offer, the consumer communicates R-c to the 
merchant by sending a message: 
OFFER-ACCEPT = R-c, OFFER-DESCRIPTION 

wherein OFFER-DESCRIPTION is included to help the merchant identify the 
10 appropriate outstanding offer. 

Now, in order to establish the validity of the bid, merchant M does the 
following. He/she 

is a. computes temporary value TMP-3 « H(MERCHANDlSE-DESCRIPTION, 
R-c); and 

b. if TMP-3 = SIG-c, he/she is satisfied that SIG-c is genuine and the bid 
valid. 

20 

The following steps c and d are optional and only executed if the merchant 
does not keep state of SIG-m. In this case, SIG-m must be included in the 
OFFER-ACCEPT communication. 

25 c. Merchant M may compute 

TMP-5 = SK-mlH(SIG-c, MERCHANDISE-DESCRIPTION, 
OFFER-DESCRIPTION)]. 

d If TMP-5 = SIG-m, merchant M is satisfied that SIG-m is his/her own 
30 signature and thus the offer is genuine. 

In this case, consumer C may transfer his/her "voucher" for the intended 
purchase to another potential consumer. Merchant M will not notice such a 
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voucher transfer. The complete process according to the above is shown in 
Fig. 2B. 

Description of Extended Process (Non-Transferable Voucher) 

The following is a detailed description of a more elaborate process. The 
described implementation offers additional advantages as described below. 

The main difference to the basic process described above is due to 
consumer C having a public key certificate and the corresponding 
public/private key pair. Because the consumer is thus able to sign his/her 
request for a bid or offer, he/she can - at a later time - prove to merchant M 
that he/she is the only one who could have generated the original request 
and who received the merchant's offer. 

Moreover, merchant M is now able to make sure that the offer and the 
merchandise are given to the same consumer, i.e., consumer C cannot 
freely transfer the offer/bid to another consumer. This entails consumer C 
revealing his/her identity to the merchant M, but only when the consumer is 
ready to purchase the merchandise; not before. 

At the same time, due to the construction of the process, merchant M 
receiving multiple requests for offers/bids from the same consumer C is 
unable to recognize this consumer as being one and the same. 

1. Consumer Request 

Consumer C wishing to obtain a bid/offer from merchant M for certain 
merchandise composes the following message, as above: 

OFFER-REQUEST = (MERCHANDISE-DESCRIPTION, SIG-c) 
wherein: 



MERCHANDISE-DESCRIPTION is the textual description of the 
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1 desired merchandise including, e.g. quantity, color/size, 
delivery dates, etc.; and 

SIG-c = SK-c[H(MERCHANDISE-DESCRIPTION, R-c)]. 

5 

SIG-c is thus the signature of the hash function digest of 
MERCHANDISE-DESCRIPTION together with a randomly-generated, 
used-only-once quantity, a nonce R-c. The preferred minimum 
recommended lenglh for R-c is 64 bits. 

10 

As before, even though R-c is used in computation of SIG-c, R-c is not 
included as part of the OFFER-REQUEST message. 

After composing OFFER-REQUEST, the prospective consumer (1) uses the 
15 anonymous communication service (3, 4) to send the message to the 
merchant (2) or a number of merchants. Any of them can read the 
description of the desired merchandise. 

2. Merchant Reply 

20 This step is identical to that in the basic process as described above and 
shall thus not be repeated here. 

3. Subsequent Actions by Consumer 

This step is also identical to that in the basic process described above and 
25 shall thus not be repeated here. 

4. Subsequent Actions 

The final step in the blind bidding method according to this part of the 
invention involves merchant M verifying the validity of the offer once 
30 consumer C decides to accept it. Regardless of how the consumer goes 
about it, the following six items of information must be communicated to the 
merchant; Cert-c is additional as compared to the basic process above. 
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1 - MERCHANDISE-DESCRIPTION 
SIG-C 

OFFER-DESCRIPTION 
SIG-m 
5 - Cert-c 
R-c 

The first four can be taken directly from the aforementioned 
OFFER-REQUEST and OFFER-REPLY messages. Cert-c is the public key 
10 certificate of consumer C and R-c is the hereto secret quantity that was use 
to compute SIG-c as explained above. 

The consumer communicates R-c to the merchant by sending a message: 

15 OFFER-ACCEPT = R-c, OFFER-DESCRIPTION, {Cert-c} 

wherein OFFER-DESCRIPTION is Included in order to help the merchant 
identify the appropriate outstanding offer. The customer's public key 
certificate Cert-c is optional. 

20 

In order to establish the validity of the bid, merchant M does the 
following. He/she 

a. verifies the validity, authenticity and data integrity of the 
25 consumer's public key certificate Cert-c, 

b. extracts the consumer's public key PK-c from Cert-c, 

c. computes value TMP-3 - H(MERCHANDISE-DESCRIPTION, R-c), and 

30 

d. computes temporary value TMP-4 = PK-c(SIG-c). 
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1 e. If TMP-3 = TMP-4, merchant M is satisfied that SIG-c is the genuine 
signature of consumer C and the bid valid. 

Steps f and g are optional and only executed if the merchant does not 
5 keep state of SIG-m. 

f. Finally, merchant M may compute 

TMP-5 = SK-m[H(SIG-c, MERCHANDISE-DESCRIPTION, 
OFFER-DESCRIPTION)]. 

10 

g. If TMP-5 « SIG-m, he/she is satisfied that SIG-m is his/her 
own signature and thus the offer is genuine. 

Variations 

is The method outlined in the previous sections can be enhanced/amended in 
the following way: 

In the event that the consumer has a priori knowledge of the merchant's 
certificate (Cert-m), the OFFER-REQUEST message can be enciphered 
20 under the merchant's public key, PK-m. This is indicated in Figs. 2A, 2B, 
and 3. The resulting secrecy of the message offers protection against 
snoopers and eavesdroppers. 

Furthermore, secrecy/privacy of the merchant's reply can be obtained 
25 if the consumer encloses a secret key in the encrypted OFFER-REQUEST, 
thus allowing the merchant to use this key for encrypting OFFER-REPLY. 

Summary of Security Properties 

The blind bidding method has the following security properties - except 
30 for the last one, all of them are valid for both the basic and the 
extended processes. 
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i — Anonymity of consumer C is maintained, e.g. while browsing before 
purchase. 

- Authenticity, data integrity and non-repudiation of the offer by 
merchant M is warranted. 

Multiple requests by the same consumer cannot be linked. This 
is a particularly important feature which essentially prevents 
the merchant M from "recognizing" a browsing customer as someone 
who has previously made purchases, even if the merchant possesses 
that customer's certificate. 

Authenticity and non-repudiation of the offer request by consumer 
M is given. 

15 

— Optionally, privacy (from eavesdroppers) of ensuing communication is 
maintained. 

Use in Products 

20 As mentioned above, the blind bidding method according to the invention 
can be used in both asynchronous, e.g. e-mail based, and synchronous 
(e.g. http- or WWW-based) electronic commerce. 

In most asynchronous environments, the necessary infrastructure already 
25 exists, i.e. there are a number of functioning anonymous remailers and 
several public key certification schemes. Electronic commerce via 
synchronous communication is currently gathering momentum and is widely 
believed to be the way of the future. The popularity of WWW-based 
commerce is a striking example. The sole missing ingredient is a 
30 synchronous protocol anonymizer. Assuming WWW, an anonymizer is a relay 
that takes incoming http requests and, acting as a proxy, connects them 
to desired points of interest while preserving the anonymity of the 



WO 97/25801 



PCT/IB96/00025 



- 21 - 

i actual incoming end-points. Of course, the replies must be similarly 
mapped back. 

A substantial part of this functionality is already provided by so-called 
5 "protocol firewalls". IBM's NetSP Secure Network Gateway is an example; 
as described above, it can easily be enhanced to serve as anonymizer in 
both directions. 

Pseudo-code for the two Processes 
10 The following is a listing of pseudo-code for the basic process 

(transferable voucher) as described above. A person skilled in the 
art should be able to adapt this code to or implement it in a given 
network environment. 



30 
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CONSUMER DEVICE: 

R-c = generate- random-number (); 
/* MERCHANDISE-DESCRIPTION assumed available */ 
/* || denotes the concatenation operator */ 
SIG-c = hash-function (MERCHANDISE-DESCRIPTION || R-c); 
OFFER-REQUEST « MERCHANDISE-DESCRIPTION || SIG-c; 
SEND (merchant, OFFER -REQUEST) ; 
receive-reply (OFFER-REPLY) ; 
/* see MERCHANT DEVICE below */ 
0 if (valid(Cert-m)) 

pa r s e ( OFFER - REPLY , OFFER -DESCRI PTION , SIG-m); 

else 

par s e ( OFFER -REPLY , OFFER-DESCRIPTION, SIG-m, Cert-m); 
if (not valid(Cert-m)) 

return-error (INVALID-CERTIFICATE); 
if (not ma t ch ( MERCHAND I SE - DESCR I PTION , OFFER-DESCRIPTION) 

return-error (INVALID-OFFER); 
parse(Cert-m, PK-ra); 
TMP-1 = Encrypt (PK-m, SIG-m); 

TMP-2 = hash-function(SIG-c || MERCHANDISE- DESCRIPTION II 

OFFER-DESCRIPTION); 

if (TMP-1 <> TMP-2) 

return-error (INVALID-SIGNATURE); 

/* at this point, the consumer device waits for the 
consumer to accept the offer */ 

if (not offer-accepted(OFFER-DESCRIPTION) 

return(); /* terminate this process */ 

/* otherwise, offer is accepted */ 

OFFER-ACCEPT = R-c; 

SEND (merchant, OFFER - ACCEPT ) ; 

.... /* at this point, the payment process is invoked */ 



WO 97/25801 



PCT/IB96/00025 



-23- 

t MERCHANT DEVICE: 

receive-request(OFFER-REQUEST) ; 

pa rs e ( OFFER - REQUEST , MERCHANDISE-DESCRIPTION , SIG-c); 

if (not valid-raerchandise(MERCHANDISE- DESCRIPTION) ) 

5 return-error (INVALID-MERCHANDISE); 

else /* compute SIG-m */ 

compose-off er (MERCHANDISE-DESCRIPTION, 
OFFER-DESCRIPTION); 

SIG-m = sign-text (SK-m, SIG-c || 
10 MERCHANDISE-DESCRIPTION || OFFER-DESCRIPTION); 

OFFER-REPLY = OFFER-DESCRIPTION || SIG-m ; 

/* optionally, append Cert -in to OFFER -REPLY */ 
if (not consumer-has-Cert-m) 

OFFER-REPLY = OFFER-REPLY || Cert-m; 

send (consumer, OFFER-REPLY) 

15 /* merchant waits until offer is accepted */ 

receive-accept(OFFER-ACCEPT) ; 

TMP-3 = hash - function(MERCHADISE-DESCRIPTION || R-c); 
if (SIG-c <> TMP-3) 

return-error ( INVALID-SIG-c) ; 

0 

.... /* at this point, the payment process is invoked */ 

This is the end of the code listing for the "Basic Process". The pseudo- 
code for the "Extended Process" (non-transferable voucher), as 
5 described above, follows. 



30 
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1 CONSUMER DEVICE: 

R-c = generate- random-number (); 

SIG-c = sign-text (hash-function (MERCHANDISE-DESCRIPTION I I R-c) 
TMP-0, MERCHANDISE-DESCRIPTION, R-c); 

OFFER-REQUEST = MERCHANDISE-DESCRIPTION | | SIG-c; 

5 SEND( merchant, OFFER-REQUEST); 

receive-reply(OFFER-REPLY) ; 

/* see MERCHANT DEVICE below */ 

if (valid(Cert-m)) 

par s e ( OFFER-REPLY , OFFER -DESCRIPTION , SIG-m); 

else 

pa r s e ( OFFER - REPLY , OFFER-DESCRIPTION, SlG-m, Cert-m); 

if (not valid(Cert-m)) 

return-error ( INVALID-CERTIFICATE) ; 
if (not mat ch( MERCHANDISE-DESCRIPTION, OFFER-DESCRIPTION) 

return-error (INVALID-OFFER); 
parse(Cert-m, PK-m); 
TMP-1 = Encrypt (PK-m, SIG-ra); 

TMP-2 = hash function (SIG-c || MERCHANDISE-DESCRIPTION II 
OFFER -DESCRIPTION); 

20 if (TMP-1 <> TMP-2) 

return-error (INVALID-SIGNATURE) ; 

/* at this point, the consumer device waits for the 
consumer to accept the offer */ 

if (not offer-accepted(OFFER-DESCRIPTION) 

25 

return(); /* terminate this process */ 

/* otherwise, offer is accepted */ 
/* Cert-c is assumed available */ 

OFFER-ACCEPT = R-c || Cert-c; 

SEND (merchant, OFFER - ACCE PT ) ; 

30 ..../* at this point, the payment process is invoked */ 
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MERCHANT DEVICE: 

receive-request(OFFER-REQDEST) ; 

parse( OFFER-REQUEST, MERCHANDISE-DESCIPTION , SIG-c); 

if ( not valid-merchandise(MERCHANDISE-DESCRIPTION) ) 

return- error (INVALID-MERCHANDISE); 

else /* compute SIG-m */ 

compose-off er (MERCHANDISE-DESCRIPTION , 
OFFER-DESCRIPTION); 

SIG-m = sign-text (SK-m, hash-function (SIG-c II 

MERCHANDISE-DESCRIPTION || OFFER-DESCRIPTION)); 

OFFER-REPLY = OFFER -DE SCRIPT I ON || SIG-m; 

/* optionally, append Cert-m to OFFER-REPLY */ 
if (not consumer-has-Cert-m) 

OFFER-REPLY = OFFER-REPLY || Cert-m; 

send (consumer, OFFER-REPLY) 
/* merchant waits until offer is accepted */ 
receive-accept(OFFER-ACCEPT) ; 
parse(OFFER- ACCEPT, R-c, Cert-c); 
if (not valid(Cert-c)) 

return-error (INVALID-Cert-c) ; 
parse(Cert-c, PK-c); 

TMP-3 = hash-function(MERCHADISE-DESCRIPTION || R-c); 
TMP-A = Encrypt (PK-c, SIG-c); 
if (TMP-3 <> TMP-4) 

return-error (INVALID-SIG-c) ; 
.... /* at this point, the payment process is Invoked */ 

This is the end of the listing for the "extended pocess". 

Though the best modes contemplated for carrying out this invention have 
been shown and described herein, it will be apparent that modifications 
and variations may be made without departing from the subject of this 
invention. 
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i CLAIMS 

1. A method for anonymous, provable information exchange between a 
sender and an addressee, e.g. bidding or auctioning, in a computer 
5 network, the latter providing 

- a public key infrastructure, preferably with certification, and 

- an anonymous communication channel available between network 
users, 

10 said method comprising the following steps: 

- said sender C composes an offer request REQ with a subject or 
merchandise description MD and a digital signature SIG-c of C ( 

15 REQ = (MD f SIG-c), 

- said REQ is transmitted via said anonymous communication 
channel to at least one addressee M, 

- said addressee M composes a reply REP with an offer description 
20 OD and his/her digital signature SIG-m, said latter being computed 

over a selection of quantities comprising at least one of MD, OD, 
SIG-c, 

REP = (OD, SIG-m), 

25 

optionally further including M's public key PK-m or public key 
certificate Cert-m, 

- said sender C, upon receiving said reply REP, uses M's public key 
PK-m ( known, transmitted, or extracted from said public key 

30 certificate Cerl-m, to encrypt said received SIG-m, thus 

determining a first temporary value TMP-1, 



TMP-1 - PK-m(SIG-m) ( 
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- and computes a concatenation of said selection of quantities on 
which said signature SIG-m is based, thus determining a second 
temporary value TMP-2 

5 

TMP-2 = H(SIG-c/MD/OD), 

- whereby the matching of said temporary values TMP-1 and TMP-2 
indicates genuineness of said offer. 

10 

2. The method according to claim 1, wherein 

- the digital signature SIG-c of the sender C is a hash function of the 
MD and/or a randomly generated nonce R-c, 

15 SIG-c = H(MD/R-c). 

3. The method according to claim 1, wherein 

- the digital signature SIG-c of the sender C is an encryption of the 
MD under a randomly generated nonce R-c as key, 

20 

SIG-c = R-c(MD). 

4. The method according to claim 1, wherein 

- the digital signature SIG-c of the sender C is a hash function of the 

25 

MD and/or a randomly generated nonce R-c, encrypted under C's 
secret key SK-c, 

SIG-c = SK-c[H(MD/R-c)]. 

30 

5. The method according to any of the claims 2 to 4, wherein 

- the nonce R-c of sender C is transmitted to the addressee M, 
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t - the addressee M computes a hash function of said MD and R-c, 

thus determining a third temporary value TMP-3, 

TMP-3 = H(MD, R-c) ( 

5 

- whereby the matching of said temporary value TMP-3 and SIG-c 
indicates genuineness of said SIG-c. 



to 6. The method according to claim 5, wherein 

- the addressee uses PK-c, either known, received, or extracted from 
Cert-c, to encrypt the received SIG-c, thus determining a fourth 
temporary value TMP-4, 

15 TMP-4 = PK-c(SIG-c) f 

- whereby the matching of said temporary values TMP-3 and TMP-4 
indicates genuineness of said SIG-c. 

20 

7. The method according to any preceding claim, wherein 

- the digital signature SIG-m of the addressee M is a hash function 
of the chosen selection of quantities of MD, OD, SIG-c, 

25 SIG-m = H(SIG-c/MD/OD), and 

- the concatenation to derive TMP-2 is a hash function of said same 
selection of quantities used to compute said SIG-m, 

3 ° TMP-2 = H(SIG-c/MD/OD). 
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t 8. The method according to any of the claims 2 to 4, wherein 

- the digital signature SIG-m of the addressee M is a hash function 
of the chosen selection of quantities of MD, OD, SIG-c, encrypted 
under M's secret key SK-m, 

5 

SIG-m = SK-m(H(SIG-c/MD/OD)). 

9. The method according to any preceding claim, wherein, 

- particularly when the sender has an a priori knowledge of the 
10 addressee's public key PK-m, the addressee M encrypts the offer 

description OD with its secret key SK-m and transmits a reply 

REP = (SK-m(OD), SIG-m). 

is 10. The method according to any preceding claim, wherein 

- the sender C further transmits its user identification ID-c to the 
addressee M as identity proof. 

11. The method according to any of the claims 2 to 4, wherein 

o - the sender C further transmits the nonce R-c to the addressee M, 

enabling identification of said sender C by verification of its 
signature SIG-c. 

12. The method according to any preceding claim, 

5 - wherein the sender C and/or the addressee M are keeping state in 

that at least one of them stores incoming requests REQ and/or 
replies REP. 

13. A syslem for anonymous, provable information exchange between a 
> sender and an addressee, e.g. bidding or auctioning, in a computer 

network, the latter providing 
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- a public key infrastructure, preferably with certification, and 

- an anonymous communication means (3,4,5,6) between network 
users (1,2) 

said system comprising: 

- means in said sender C (1) for composing an offer request REQ — 
(MD, SIG-c) with a subject or merchandise description MD and a 
digital signature SIG-c of C, 

- means for anonymizing said offer request REQ, 

- means for transmitting said anonymized offer request to at least 
one addressee M, 

- means in said addressee M for composing a reply REP = (OD, 
SIG-m) with an offer description OD and a digital signature SIG-m 
of M, said latter being computed over a selection of quantities 
comprising at least one of MD, OD ( SIG-c, optionally further 
including M's public key PK-m or public key certificate Cert-m, 

- means in said sender C, upon receiving said reply REP, for 
encrypting said received SIG-m and determining a first temporary 
value TMP-1 = PK-m(SIG-m), using M's public key PK-m, known, 
transmitted, or extracted from said public key certificate Cert-m, 

- means for computing a concatenation of said selection of quantities 
on which said signature SIG-m is based and determining a second 
temporary value TMP-2 = H(SIG-c/MD/OD), 

- means for comparing said first and said second temporary values 
TMP-1 and TMP-2, whereby their matching indicates genuineness 
of said offer. 
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Fig.1 



PK-m 




REQ = MD, SIG-c 
REP = OD, SIG-m 



TMP-1 = PK-m(SIG-m) 
TMP-2 = H(SIG-c, MD, OD) 




Fig. 2A 
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PK-m 




REQ = MD, SIG-c 
REP = OD, SIG-m 
ACC = MD, R-c 



TMP-1 = PK-m(SIG-m) 
TMP-2 = H(SIG-c, MD, OD) 

TMP-1 = TMP-2 




TMP-3 = H(MD, R-c) 
TMP-3 = SIG-c 



Fig. 2B 



PK-m 




REQ = MD, SIG-c 
REP = OD, SIG-m 



ACC = OD, R-c, {Cert-c} 



TMP-1 = PK-m(SIG-m) 
TMP-2 = H(SIG-c, MD, OD) 




TMP-3 = H(MD, R-c) 
TMP-4 = PK-c(SIG-c) 



TMP-1 = TMP-2 



TMP-3 = TMP-4 



Fig. 3 
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